An Interactive Voice Response (IVR) system in its simplest form automates the process of directing calls to the appropriate individual. In recent years, however, IVR systems have evolved into very complex computerized voice applications that enable callers to order products, for example, over the telephone and without ever being connected to a human being. Such systems require tremendous human effort to develop and maintain due to a large number of interconnecting dialog states. A dialog state may be thought of in terms of the information between when a caller provides an input and when the system waits for the next input (e.g., pressing of a number on a telephone handset or a verbal command) from the caller in order to determine a next dialog state. For example, a caller to a pharmacy may be first instructed to “press 1 for English or press 2 for Spanish,” If the caller presses “1”, then the IVR system traverses to an English language dialog state where the user is prompted to “enter 1 to refill your prescription; 2 to speak with a pharmacist; or 3 to check the status of your refill order.”
IVR applications are constructed in a similar manner to standard computer applications and HTML web pages. In fact, Voice eXtensible Markup Language (“Voice XML” or “VXML”) is a simple Extensional Markup Language standard created specifically for developing IVR applications. As stated in the VXML 2.0 specification, VXML is designed for creating audio dialogs that feature synthesized speech, digitized audio, recognition of spoken and one Dual-Tone Multi-Frequency (DTMF) key input, recording of spoken input, telephony, and mixed initiative conversations. Its major goal is to bring the advantages of Web-based development and content delivery to interactive voice response applications.
While the language standard may be simple, the IVR applications that are built off of it may be incredibly complex and thereby difficult to test. Traditionally, system testers take on the role of end users by calling the IVR system and interacting with the system as would be expected from an average end user. Therefore, it is easy to appreciate that testing very large and complex systems requires the expenditure of many man-hours and further requires attention and patience.
In recognition of the problems associated with creating, testing, and maintaining IVR applications, tools have been developed to assist in the testing process. Load testing tools include a call-processing unit that places a number of simultaneous and/or repeated calls to the IVR application. While these tools have the ability to detect deviations in application response (e.g., length of pause between inputs, length of audio cues, system hang-ups, etc), these tools do not provide insight into the actual behavior of the voice application. The test scripts used in such load testing, in the prior art, must be manually created and then later updated each time the application is changed. Moreover, testing only goes so far, and the real test of an IVR application is how it performs when it is used by actual users. But systems and methods for understanding how such systems perform have been lacking.
Businesses have a long felt need for understanding how their IVR systems are actually performing. They need this information in order to identify issues within their IVR systems and how to address those issues. IVR performance information may also be useful to identify opportunities to improve the IVR application. By way of example, businesses would like to know how many people were serviced by their IVR system, which call paths were used, whether the callers were successfully serviced, which options are used the most, and which business transactions were invoked using the IVR. Furthermore, it would be useful to know how long it took to complete key business transactions. These and other similar types of statistics are useful for optimizing IVR services and improving customer satisfaction.
Some existing IVR platforms do not support the generation of statistics about the performance of the IVR system. Other existing IVR platforms only support such statistic gathering in a proprietary format. For example, IVR application developers may add code to their applications to track certain statistics. These proprietary solutions involve the development of unique code for each application and this is an expensive and time consuming proposition. Moreover, IVR systems will often be changed over a system's lifetime, and such proprietary statistics related programming often has to be updated each time changes are made to the IVR system. Thus, proprietary embedded statistics gathering programming is generally undesirable.
In yet another approach for obtaining IVR operation statistics, some applications are configured to parse the log files generated by an IVR application, teach a tool to interpret the application specific log statements in those log files, and then use this information to generate certain statistics. This approach also has several drawbacks. First, tool training is time consuming and the tool may have to be retrained any time the application changes. As mentioned above, IVR applications tend to be changed with some frequency, and any change has the potential to effect the log statements, so this is a non-trivial issue. Second, the statistics are only obtained through post processing of the generated log files. Thus, the statistics can not be obtained “live.” Third, the if the application was not configured to log a particular event, that event can not be used to generate any statistics. Thus, the opportunities to measure certain statistics may be inherently limited by the IVR application itself.
Thus, new systems and methods are needed to improve the ability to obtain statistics on the operation of voice applications in IVR systems.